~~NOTOC~~
====== IOB Data Analysis =====

=====  Current activities: Pending/ongoing  ===== 
----

-- Finish the clean-up of Python code. \\
-- Re-think event categories, and include events not classified yet. \\
-- Improve accuracy on event counts and fluence adjustment. \\
 
  * Reminder for Gary:  
    * <del>Obtain DUT outputs grouping information: LVCMOS, IOSERDES.</del> (Uploaded to wiki: design files).
    * <del>Provide docs on detail engineering of IOB & IOSERDES tests.</del> (Uploaded to wiki: design files).
    * Obtain DUT outputs grouping information: HSTL (Raytheon's design that went into the beam).
    * Test FUNCMON<->DUT in Lab, to see if we can replicate the HSTL / IOSERDES strange patterns. 
    * Confirm V-5QV data to compare with.
    * Provide CONFIGMON (& JCM) & PWR logs information to classify SEFI/Global upsets.
    * Provide UCD proton tests FuncMon raw data.


=====  Current activities: Recently done  ===== 
----
  * Checked the anomalous delta-counts issue. Three runs with a factor of 2 in 2016.12 LVCMOS(3V3) un-registered tests, and cases with factors of 0.5, 1.5 and 2 are appearing in 2017.03 IOSERDES tests (inherently registered tests). No complete explanation so far.  
  * **(Done the following; only few [configuration upsets] data recovered)**  \\  Apply script to December (TAMU) data, now with (Gary's suggested) glitches' filter. This will bring some more information on the test procedure, regarding the HSTL/IOSERDES strange patterns issue. Also, will add some more LET points, and information about performance of HR (3V3-std.) outputs.\\ 



===== General notes ===== 
----
  * Unless otherwise mentioned, the data comes from **FuncMon logs**. 
  * All **HP** IOBs (V7-980T).
  * Here we work within a **semi-automatic process**. The automatic portion is based on a Python script (mainly around Pandas data analysis library) just in its infancy, and evolving. There are many factors playing against achieving a completely automatic script; anyway, the goal here is to simplify the processing and provide a systematic/repeatable framework for beam test data analysis. 
  * The **test run numbering ** used here is the one automatically generated by the Python script, at the moment of identifying each test run (based on corresponding time windows specified in the facility summary file). This is different, in general, to the manual numbering defined at testing time. The correspondence between both is documented in a table provided by the Python script. This "test run window identification" first stage of processing is applied to all the raw data (i.e., not only to the raw files that we assume correspond to IOB tests). 
  * **NOTE:** On Sunday 2017.03.12, **Daylight Saving Time started**. When local standard time was about to reach 2017.03.12 02:00, clocks were turned forward 1 hour to  2017.03.12 03:00 local daylight time instead. This jump appears indeed both in the facility summary file 'FacilityLog_TAM0317_Day2-3.REP', and in the corresponding FuncMon (.LGF) log file. Though the time window matching algorithm works well for the Beam Off->On transition, it is still fooled on the Beam On->Off transition time matching, because the FuncMon log transition is compared to the "live+dead" time (involving a delta-time added to an initial absolute time instant). Instead of modifying both the .REP file and the .LGF file, this was hardcoded in the python script, loading manually the affected test run (testrun062 as per the algorithm numbering).
  * Raw data files provide a sea of information, and it's easy to get lost in there. **Heatmap-style graphic plots of delta-count values ** are //used as auxiliary guide-maps//, to detect interesting events by inspection, dive into the corresponding raw file, confirm the signature of the upset, and go back to iterate/debug over the script. And, of course, for team analysis/discussion during the remote meeting sessions. Furthermore, it is worth to note that this graphical method has enabled the detection of subtle effects, otherwise very difficult to perceive or discriminate (e.g., the apparent signatures detected in HSTL test runs). In summary, it started as a toy and at some point it became an important tool, whenever is used with criteria. At this point, it is still not perfect and is important to verify any interesting new feature  with the actual data.  
  * In general, an IOB block test consists in a ** loopback setup,** with FuncMon FPGA driving a given DUT input, the latter being internally routed to a "group" of N (e.g., N=4) //nearby// outputs; finally, each of the DUT outputs in a given group are driving corresponding FuncMon inputs. As an alternative "registered" test, we can also loopback passing through DUT registers. The FuncMon FPGA injects a bit pattern to the DUT input, and expects to receive the same pattern from the N DUT outputs, otherwise it increments an error counter.
  * With the exceptions of the test runs corresponding to HSTL and IOSERDES, here the system is ** "packing" the LSBytes of the internal FuncMon 32-bit error counters ** corresponding to the (more than 64) DUT outputs, into the 32-bit Counter[63:0] "placeholders" available in FuncMon's GUI and log files. This imposes some important constraints in the ability to detect upset signatures, as follows:
    * As now we effectively have 8-bit counters, when we have a CRAM hit these are constantly overflowing. This means that now we have both positive and negative delta-counts, in a "normal" situation. Remember,  with full 32-bit counter visibility we have negative deltas only in "special" cases; e.g., counter reset, counter overflow. 
    * Due to the mentioned limitation, we can consider "small delta-counts" to correspond to an SEU (delta = 1) or an MCU (delta > 1), only in cases where these deltas appear "isolated in time". That is, surrounded by "delta = 0" in the time sequence of the corresponding error counter. In other words, we can't discriminate between the following two classes:
      * burst of "free-running" counters;
      * burst of "small delta-counts".  


===== Specific IOB standards ====
----

The following sections comments on the data analysis for each considered variant of IOB standard.
 
  * ** [[data_analysis:v7-dynamic:201703-tamu:iob:hstl| HSTL standard ]] ** 
  * ** [[data_analysis:v7-dynamic:201703-tamu:iob:lvcmos| LVCMOS standard ]] **  


===== Python code ====
----

NOTES: 

-- The following code is a preliminar version. \\
-- The .LGF log files of the test must be provided inside raw_data folder. \\

  * ** {{data_analysis:v7-dynamic:201703-tamu:iob:20170310-tamu-v7-980t-funcmon.zip| 20170310-tamu-v7-980t-funcmon.zip }} ** 

